home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 3321 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.1 KB
  1. Path: news.ultranet.com!usenet
  2. From: "Albert P. Belle Isle" <belleisl@cerberus-sys.com>
  3. Newsgroups: alt.winsock,alt.winsock.trumpet,comp.dcom.modems
  4. Subject: Re: Is 2K(bytes) per second avg reasonable x-fer rate for 28,800 V34 modem?
  5. Date: 30 Jan 1996 17:33:34 GMT
  6. Organization: Cerberus Systems, Inc.
  7. Message-ID: <4elkpe$7is@caesar.ultra.net>
  8. References: <4edrr2$bcr@nntp.ucs.ubc.ca>
  9. NNTP-Posting-Host: apb-p5-90.cerberus-sys.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.22 (Windows; I; 16bit)
  14.  
  15. cree@unixg.ubc.ca (Robert Ree) wrote:
  16. >I just downloaded the Eudora EU154b11.EXE file at 2,036K from
  17. >Qualcomm's FTP site via  Al Junod's  32bit WS_FTP, and it took just
  18. >over 16 minutes.  
  19. >
  20. >Am I calculating this correctly:
  21. >
  22. >A 2,036K file took 16+ minutes to download. 16*60=960, so lets say
  23. >1,000 seconds (rounding up) to download 2,036Kilobytes, which is 2K+ a
  24. >second.
  25. >The rate shown by WS-FTP during download varied from 3.1 down to 1.6
  26. >but most often was shown at 2.14.
  27. >
  28. >2Kilobytes a second would be 2K*8=16Kilobits a second, or 16,000 bps.
  29. >
  30. >Equipment:
  31. >
  32. >486dx33
  33. >12MEGS
  34. >Hayes ACCURA 28,000 V34 - internal (16550 UART supposedly ...)
  35. >Windows95 internal 32bit TCP/IP stack (DUN)
  36. >Connection with IP  establlished at 115,200bps
  37. >Other than RoboDUN, no other windows open.
  38. >
  39. >Is this the best I can expect?
  40. >
  41. >Who has some numbers to compare this with?
  42. >
  43. >Thanks.
  44. >
  45. >Robert
  46. >
  47. >
  48. >
  49. >
  50. >Equipment:
  51. >
  52. >
  53. >----------------------------
  54. >Robert Ree
  55. >e-mail: cree@unixg.ubc.ca
  56. >-----------------------------
  57. >
  58.  
  59. Robert:
  60.  
  61. I think you'll find that the best that a TCP/IP session can do over a 
  62. SLIP or PPP connection is limited by the speed of the modem. A 28.8Kbps 
  63. modem can never keep up with a 1544 Kbps (or faster) internet path. 
  64.  
  65. (Although, if your retail access provider buys his wholesale access at 
  66. 56Kbps, you might never get the chance to try <g>.)
  67.  
  68. With an uncompressible (already compressed) file, you should be able to 
  69. get 3.2KBytes/sec for a 28.8Kbps connection, 2.7KBytes/sec for a 24Kbps 
  70. connection, etc. Obviously, downloading compressible files should give 
  71. correspondingly greater effective transfer rates with V.42bis data 
  72. compression.
  73.  
  74. (This, of course, has nothing to do with Van Jacobson header compression 
  75. - the disabling of which could drop 3.2KBytes/sec to 3.1 or even 3.0 
  76. KBytes/sec, depending on packet size.)
  77.  
  78. If you observe such transfer rates at some points in a download, but the 
  79. overall average is less, that average had to have been reduced by pauses 
  80. between TCP/IP packet transfers.
  81.  
  82. If the pauses were just due to the fact that the server was too busy to 
  83. send as fast as you could receive, turning-on TCP Trace (if you were a 
  84. Trumpet WinSock user) would show a smooth sequence of MSS-sized segment 
  85. transfers, but with pauses. In that case, if you turned-on Trumpet 
  86. TCPMeter, you'd be able to open a second window to another server and see 
  87. yourself using the difference between the average file download rate and 
  88. 3.2KBytes/sec for a second download from that different server.
  89.  
  90. If the problem was IP routing congestion on the then-available paths 
  91. between you and the server, RTOmax time-outs by the server (waiting for 
  92. your ACKs) would cause him to re-transmit, resulting in "unacceptable 
  93. segments" and TCP re-synchronization pauses. (Out-of-order segments that 
  94. took different routing paths through the Internet could cause similar 
  95. pauses.)
  96.  
  97. There's not much you can do about a busy Internet.
  98.  
  99. However, if you failed to ACK because of damaged packets, you might be 
  100. experiencing PPP frame check errors, which would also result in pauses 
  101. for re-transmission.
  102.  
  103. These could be due to com overrun errors caused by your machine not 
  104. servicing com port interrupts fast enough to keep up with the rate you 
  105. promised the modem in your com port setting.
  106.  
  107. They could also be due to inadvertently disabling your V.42 error 
  108. correction, which you might not notice on a very clean phone line. (On a 
  109. line with any amount of noise, you'd find that the error rate would swamp 
  110. TCP/IP and that PPP would probably hang-up your connection.)
  111.  
  112. These are problems in your data link layer, and should be eliminated.
  113.  
  114. Similarly, if you and the server agreed on a TCP MSS that was not less 
  115. than the smallest IP MTU of all the routers between you (minus 40 bytes 
  116. for headers), you'd be getting slowdown from IP packet fragmentation.
  117.  
  118. If your TCP RWIN was set to more than the size of the number of TCP data 
  119. segments that would fit in the number of IP packet buffers your Internet 
  120. service provider allocates per dial-in port, the resulting dropped 
  121. segments would also cause re-transmission pauses.
  122.  
  123. These are problems in your TCP/IP layers, that should also be eliminated.
  124.  
  125. I've put together a tutorial on WinSock speed-tuning at the URL listed in 
  126. my signature block, if you're interested in further elaboration (with 
  127. real words substituting for the acronyms <g>).
  128.  
  129. Regards,
  130.  
  131. Al
  132.  
  133.  
  134. -- 
  135. ==================================================================
  136. Albert P. Belle Isle
  137. Cerberus Systems, Inc.
  138.  
  139. Al's Winsock Tuning FAQ -
  140.        http://www.cerberus-sys.com/~belleisl/mtu_mss_rwin.html
  141. ==================================================================
  142.  
  143.  
  144.